  <div class="docs" id="bestpractices">
<h2>Key Open Source "Best Practices" supported on this site</h2> 

  <p>Software engineering practices are key to any large development project. This site provides a home to conduct open source or collaborative software projects integrated with a set of hosted development tools to facilitate project teams adopting the "best practices" that have proven themselves in the open source community.</p>
  <h3>Technical Communication</h3> 

  <p>Software developers spend a large part of their time communicating with each other. Clear and effective technical communications are needed to keep the team in synch and to allow individuals with key knowledge to apply that knowledge where it is needed.i</p>

  <p>One tenet of the open source community is that technical communications should take place in public forums. Mailing lists are the backbone of open source communications. Beyond that, open source projects need support for precisely communicating technical details and for group decision-making.</p>
  <h3>Version Control, Document Management, and Distribution</h3> 

  <p>Every software development project needs version control. Open source projects need strong and flexible support for many concurrent developers working on overlapping sets of files. Open source projects also need standard templates for design documents, technical documentation, and end user documentation.</p>

  <p>A well-organized project should facilitate distributing these documents. But, the nature of open source projects demands that these files are globally accessible, and that administrative overhead be minimized and responsibility be spread out over the members of the development community.</p>
  <h3>Quality Assurance</h3> 

  <p>Open source software products have achieved a remarkable degree of quality. This is something that the closed source development world has found to be one of the most difficult and costly aspects of software development.</p>

  <p>Open source software is high quality for three main reasons:</p>

  <ol>
   <li>Developers are self-selected by their interest and knowledge of the application domain.</li>

   <li>Requirements are tacitly understood by developers who are themselves users of the software.</li>

   <li>Technical communications (including bug reports) are conducted in public. The public nature of open source helps developers take pride in their successes and think twice before releasing faulty code.</li>
  </ol>

  <p>Furthermore, debugging is much more effective when split among many people who have diverse knowledge.</p>
  <h3>Build and Test Management</h3> 

  <p>Development activity on open source projects is constant and concurrent among many developers. Sometimes the changes made by one developer interfere with those made by another developer.</p>

  <p>Often the version control practices used in the open source community resolve these conflicts, but sometimes they do not. Frequent automated builds and tests of the software being developed are powerful tools that help catch logical conflicts early.</p>
  <h3>Project Management</h3> 

  <p>Every project needs explicit goals, resources, and a schedule. The open source community has addressed these issues in a uniquely flexible way. Shared "to do" lists keep track of tasks that need to be done. Personal "to do" lists keep developers on track. Milestone lists set flexible deadlines for individual features based on feedback from users and developers.</p>
  <h3>Knowledge Management</h3> 

  <p>Knowledge is the valuable resource that sets experienced developers apart from novice ones. Sharing knowledge effectively has been key to the success of the open source community. Explicitly managing knowledge can help reduce the learning curve for novices which reduces the barriers to entry for potential contributors while automatically keeping the load on the experts down to a minimum in terms of training others.</p>
 </div>



